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The RICIS Concept 


The University of Houston -Clear Lake established the Research Institute for 
Computing and Information Systems (RICIS) in 1986 to encourage the NASA 
Johnson Space Center (JSC) and local industry to actively support research 
in the computing and information sciences. As part of this endeavor, UHCL 
proposed a partnership with JSC to jointly define and manage an integrated 
program of re search in advanced data processing technology needed for JSC’s 
main missions, including administrative, engineering and science responsi- 
bilities. JSC agreed and entered into a continuing cooperative agreement 
with UHCL beginning in May 1986, to jointly plan and execute such research 
through RICIS. Additionally, under Cooperative Agreement NCC 9- 16, 
computing and educational facilities are shared by the two institutions to 
conduct the research. 

The UHCL/R1CIS mission is to conduct, coordinate, and disseminate research 
and professional level education in computing and information systems to 
serve the needs of the government, industry, community and academia. 
RICIS combines resources of UHCLand its gateway affiliates to research and 
develop materials, prototypes and publications on topics of mutual interest 
to its sponsors and researchers. Within UHCL, the mission is being 
implemented through interdisciplinary involvement of faculty and students 
from each of the four schools: Business and Public Administration. Educa- 
tion, Human Sciences and Humanities, and Natural and Applied Sciences. 
RICIS also collaborates with industry in a companion program. This program 
is focused on serving the research and advanced development needs of 
industry. 

Moreover, UHCL established relationships with other universities and re- 
search organizations, having common research interests, to provide addi- 
tional sources of expertise to conduct needed research. For example, UHCL 
has entered into a special partnership with Texas A&M University to help 
oversee RICIS research and education programs, while other research 
organizations are involved via the ‘‘gateway’ concept 

A major role of RICIS then is to find the best match of sponsors, researchers 
and research objectives to advance knowledge in the computing and informa- 
tion sciences. RICIS, working jointly with its sponsors, advises on research 
needs, recommends principals for conducting the research, provides tech- 
nical and administrative support to coordinate the research and integrates 
technical results into the goals of UHCL, NASA/JSC and industry. 
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Preface 


This report satisfies deliverable number 5 of RICIS contract #069. The purpose is to document results of 
the four Expert Systems Verification and Validation workshops taught during the period of March 1992 to 
August 1992. 
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Final Report 


Background 


Five workshops on Verification and Validation (V&V) of Expert Systems (ES) where taught during this 
recent period of performance. Two key activities, previously performed under this contract, supported these 
recent workshops. 

L Survey of state-of-the-practice of V&V of ES 

2. Development of workshop material and first class 

The next two section describe these activities in more detail. 


Survey 

The first activity involved performing an extensive survey of ES developers in order to answer several 
questions regarding the state-of-the-practice in V&V of ES. These questions related to the amount and type 
of V&V done and the successfulness of this V&V 1 . The answers to these questions led us to two primary 
conclusions: 

1. The state-of-the-practice in V&V of ES needs to be improved. This conclusion came from the lack of 
V&V techniques used, the fact that many systems did not meet expectations, and other results that indi- 
cated a relatively unstructured approach to V&V. This does not necessarily mean that the systems being 
developed were of poor quality or that the developers were not trying; in fact, many project spent a 
considerable amount of time doing V&V, in some cases up to 80% of the effort was spent on V&V 
activities. The results only indicate that many systems did not meet expectations and the V&V approach 
appeared inadequate in most cases. 

2. A great improvement in ES V&V could be achieved by using existing V&V techniques and methods. 
That is, although ES V&V is still an active research area with many unsolved problems, there are still 
many existing methods and techniques that are just not being used. Furthermore, many of these 
methods and techniques are ones that are being applied to conventional (i.e., non ES) software. It 
seemed as though the large body of knowledge about general V&V was not being applied to ES. 

These conclusions led us to believe that a class on V&V, with a special emphasis toward ES, would be of 
great value in improving the state-of-the-practice in ES V&V. Specifically, we wanted to inform developers 
about: 

1. basic V&V concepts 

2. the most useful V&V methods and techniques 

3. differences between ES and conventional software 

4. V&V technques specifically for ES 

Additionally, we hoped to provide some hands-on experience with these techniques. 

Workshop Development 

The next key activity involved developing an intensive hands-on workshop in V&V of ES. This activity 


1 The full results of this survey has been delivered in a previous report under this contract 
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involved surveying a large number of V&V techniques, conventional as well as ES specific ones. 2 

In addition to explaining the techniques, we showed how each technique could be applied on a sample 
problem. References were included in the workshop material, and cross referenced to techniques, so that 
students would know where to go to find additional information about each technique. 

In addition to teaching specific techniques, we included an extensive amount of material on V&V concepts 
and how to develop a V&V plan for an ES project. We felt this material was necessary so that developers 
would be prepared to develop an orderly and structured approach to V&V. That is, they would have a 
process that supported the use of the specific techniques. 

Finally, to provide hands-on experience, we developed a set of case study exercises. These exercises were to 
provide an opportunity for the students to apply all the material (concepts, techniques, and planning mate- 
rial) to a realistic problem. 

First Class and Review of Workshop 

Through our previous work, we had made contacts with a number of leading researchers in the area of ES 
V&V. We sent copies of our workshop material to these researchers and solicited their feedback and we 
updated the material based on their feedback. It is worth noting that we received many positive comments 
about the workshop material and our plans to teach it to ES developers. Based on this review, we felt confi- 
dent that we had a solid and comprehensive set of course material. 

The next review step was to present an overview of the material to a group of people knowledgeable in ES 
but not experts in ES V&V. This review gave us an opportunity to find out how well we could communicate 
the information to practitioners. A number of concerns were raised at this review. We addressed these con- 
cerns primarily by adding material to explain the role and purpose of V&V in ES development. This review 
was at the end of the previous phase of this contract (February, 1992) and constituted the first class. 


2 In particular, we capitalized on previous work done by Lance Miller of Science Applications International Corpo- 
ration in support of a contract to the Electrical Power Research Institute and the Nuclear Regulatory Commission. 
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Teaching the Workshop 


The first full class was taught in March of 1992 to a select group of ES developers and software V&V profes- 
sionals. The students were arranged by the NASA JSC Software Technology Branch (STB). This class lasted 
three full days. 

At the end of this first class, we, along with Chris Culbert and Bebe Ly of the STB conducted an interactive 
discussion with the students on the value of the material and suggestions for improvement. It was felt that 
the material was very valuable and did need to be taught to others. For example, one student said that they 
had been doing V&V for six years (and had to leam things on the job), but still learned some new things in 
the class; “I just wish I had had this class six years ago” , they said. 

We also learned many ways the material could be improved and the way it was presented could be 
improved. We learned that more time was needed for exercises and the order of presentation needed to be 
revised. Based on the recommendations and further analysis of the course material, an improved version of 
the workshop was produced. The new version had a new outline that allowed us to interleave lectures and 
the case study exercises, rather than having the students do all the exercises at the end of the class. We also 
added some videotaped demonstrations to further break up the lectures and make the class more interesting. 
This new version required four days to teach, instead of three. 

To solicit students for additional classes, we developed a flyer that the STB circulated for us. We had sched- 
uled three additional classes and received enough responses to hold each class. 1 

The additional classes did not indicate a need to modify the existing material, though some new material was 
added. The new material was in the form of worksheets that walked the students, step by step, through 
applying several of the more advanced techniques. Examples of the kind of work performed by the students 
is in “Attachment B” on page 11. 

Computer-Based Training Prototype 

To support the advertisement of the workshop, IBM prototyped a multimedia introduction to the course. 
This presentation is centered around a problem situation that occured during the Apollo 1 1 lunar landing. 
This problem is an intriguing example that can be used to discuss many V&V concepts and motivate people 
to attend the workshop. 

The development of this prototype resulted in a new item being added to the contract. This item involves 
providing assistance to the STB in the development of an expanded multimedia computer-based training tool 
that illustrates concepts from the workshop. 

Management Overview 

One major goal of the workshop was to “sell” developers on the importance of V&V activities. In general 
we were very successful. Most students indicated a belief that the ideas taught were the “right way to go.” 
However, they also indicated that teaching their managers these same concepts would increase the likelihood 
of their success in applying them. 


3 Refer to “Attachment C” on page 13 for a complete list of workshop attendees. 
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Therefore, we developed a two hour management overview 4 . The management overview' covers the same 
basic concepts of V&V without focusing on techniques. The idea is to tell managers why V&V is beneficial 
and how they can help their ES project developers as they try to apply the ideas taught in the workshop. At 
this point, however, the management overview has not been taught. 


4 Refer to "Attachment D" on page 15 for a copy of the management overview. 
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Results 


Overall, the workshops were very successful. The evaluation scores shown in “Results of Student 
Evaluations” on page 7 reflect that success. We also received many positive comments about the value of 
the material. However, it is still too early to detect any long-term impact of the class on current V&V prac- 
tice. Activities are underway, however, to begin assessing this long-term impact. 

As with any successful job, however, there is always room for improvement. The remainder of this report 
will focus primarily on areas where the workshop could be improved. These areas of improvement have 
been derived from informal discussions with the students, student evaluations and instructor observations. 


Student Profile 

In order to put student comments/evaluations into perspective, it is helpful to consider the profile of the 
students that attended each of the workshops. This section describes that student profile and how it 
impacted the successes and shortcomings of the workshop. 

The ES V&V workshop was taught five times during the period of March 1992 to August 1992. The work- 
shop in March was substantially different from the others held from May to August. This was the case for 
several reasons: the class material discussed fewer techniques, the class was shorter (three days instead of 
four), and the students were “hand-picked” to attend and give valuable feedback on the first class. Since the 
students were “hand-picked” for the March class, the attendance was very good (a consistent twenty-one 
each day of the class). 

Many helpful suggestions were implemented as a result of the March workshop. In addition, a flyer was 
distributed by the Software Technology Branch (STB) to advertise the next four workshops (May through 
August). People wishing to attend the workshop were asked to either call IBM or the STB to register for 
the workshop. As we learned later, more time should have been spent screening people requesting to attend 
the class. The flyer indicated that the workshop would be of primary interest to those currently working ES 
problems. However, the background of the students actually attending the workshop reflected a broader 
scope of interest. The following statements reflect comments made to the instructor by students when 
describing their reason for attending the workshop: 

• “I am here because my manager signed me up” 

• “I am here to learn about ES; I do not care about V&V.” 

• “I am here to learn about V&V; 1 do not care about ES.” 

• “I am here to learn how to use ES to do V&V” 

• “I do not know why I am here; I am a programmer. I do not do testing.” 

Unfortunately, the difficulty in finding the right students for the workshop meant that student attendance 
was not as good as the March workshop. With the exception of the June workshop, each of the workshops 
started with 15 or more students (our goal was to have at least 20). Attendance, however, steadily dwindled 
each day to the point where the workshop usually ended with only one-half to two-thirds of the original 
students still in attendance. It should be noted that many who stopped attending did so because of demands 
on the job. Yet, many left because they thought the workshop was going to be something that it was not. 
We have attempted to address this issue by asking each student to fill out a questionaire, indicating what 
information they would most like to get out of the class. We then use this information to focus the lecture 
time on information of the most interest. However, the best solution in the future would be to better com- 
municate the goals of the class to each prospective student, so we can be sure that the class meets the stu- 
dents needs and expectations. 
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An example of this latter point is evident in the number of students who had no idea what rule-base pro- 
gramming was all about. In the “Basic Concepts” section of the workshop, an example of a rule-based 
program and a procedural program are contrasted to illustrate key impacts of “AI” languages on V&V. In 
the March workshop the rule-based example was written in CLIPS. Roughly one-third of those students 
knew nothing about CLIPS. Therefore, we spent about an hour explaining the basics of CLIPS. To avoid 
this problem in future classes, the CLIPS examples were modified to use a English-like pseudo language (still 
rule-based). The idea was to remove the requirement to know CLIPS syntax. This only partially solved the 
problem, because anywhere from one-third to two-thirds of the workshop students in the next workshops 
did not know anything about rule-based programming or any AI language (in the case of the June work- 
shop, there was only one student in the class that knew anything about rule-based programming). This 
increased the difficulty in contrasting ES and procedural V&V issues. 

Some of the dissatisfaction with the material on techniques may be due to the state-of-the-art in ES V&V. 
As with software in general, there is no “silver bullet” as some would like to find. Instead, there are only 
techniques that require discipline and skill to apply. Students that worked hard to apply the tehmques on the 
team exercises generally had a more positive response to the workshop. However, some students (as evi- 
denced by some of the responses in “Attachment B” on page 11) expended minimal effort on the exercises. 
The reasons for this are not clear but may be due to the discipline required to apply many of the techniques. 
For example, one of the better techniques for evaluating rule-based programs is to generate “connectivity” 
matrices. This technique is good because it is relatively easy and could easily be automated with off-the-shelf 
matrix operations routines. But it is somewhat tedious and only finds anomalies that must be analyzed to 
determine if they are faults or not. Thus, it requires discipline and definitely is not a “silver bullet” solution. 
One student indicated that they had learned about matrices in school and did not want to have to use them 
anymore. We recognize that some of the techniques are somewhat unpleasant and not “fun” to use. It is for 
this reason that we are recommending that a significant effort be made to select the best techniques and then 
automate them. 

We attempted to teach about techniques and also about developing a V&V approach. The information 
required to develop a V&V approach is much less than what is required to master the techniques. So we 
were able to thoroughly cover V&V p lanning but, could only introduce each technique. To thoroughly cover 
each technique would have required an order of magnitude more time, something on the order of a one- 
semester college course. We attempted to overcome this shortcoming by providing extensive references which 
were cross referenced to techniques. We also provided a set of worksheets that would help a student follow 
each technique in a step by step fashion. Still, many students would have rather covered fewer techniques, 
but covered them more in depth. We feel the best way to resolve this issue is to teach a class that covers one 
or two development methodologies that support V&V. The methodology would be composed of a few tech- 
niques that work together well and address a wide range of V&V. 

Students who are technical project leads found the class very exciting and rewarding. This was because they 
did not need as much detailed information. Instead, they just needed a general overview of issues that they 
need to consider in leading their projects. Many of these students explicitly said, “I am going to start using 
this information on my project.” Others indicated that this class will be very helpful as a “reference” when 
“planning for V&V” on their project. 

On the other hand, students who came to get specific help on specific problems found the experience less 
rewarding because the workshop was not geared for that. For example, one particular student attended the 
class wishing to receive specific help in verifying a G2 rule-base. Rather than focusing on specific problems 
like this one, the workshop tried to address broader information about V&V concepts, issues and 
techniques 5 . In some cases, though, the information was too broad, because many students had a stronger 
background in the concepts of V&V than we anticipated. This was not necessarily a big problem (i.e., some 


5 The survey results indicated that most ES projects were built by people with little training in V&V (i.e. t they were 
engineers, flight controllers, etc. - not programmers). 
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enjoyed the review of V&V concepts), but reflects on why some of the evaluation comments indicated there 
should be less emphasis on “basic concepts.” 

The workshop was definitely geared to students whose jobs are in the technical area of systems development. 
However, it soon became clear that many approaches being advocated in the class would be difficult for the 
student to do without significant commitment from their management. Many students brought this concern 
to the attention of the instructors. A good example of this is found in the team exercise solutions of 
“Attachment B” on page 11. One group indicated that they would not use the technique of inspections as 
part of their V&V approach. Their reason? “My management will not pay for inspections.” This answer 
was given despite a thorough presentation on the benefits of inspections 6 . 

In summary, a better job Of “screening” students and a better job of communicating the course intent should 
solve many of these problems. The objective of each workshop was clear: provide information on V&V 
and encourage people to use V&V techniques on ES (i.e., V&V of an ES can be done, despite what a 
student may have heard to the contrary). The purpose was not to make the student an expert on using each 
technique or to teach expert system programming techniques/languages. To this end, the class, at least so 
far, has been very successful. 


Results of Student Evaluations 

Rating (1 *= High, 5 - Low) 

Category 

1.9 


Quality of course material 

1.6 


Effectiveness of Instructors 

2.1 


Depth of course content 

1.7 


Degree to which the course met its stated objective 

1.9 


Effectiveness of the delivery method 

2.0 


Relevance of the course to my job requirements 

1.9 

Confidence in my ability to apply the course content to my job 

2.0 


Course exercises 

2.3 


Length of course 


Student Comments/Suggestions 


The following items are a condensation of comments received from students at the bottom of the class evalu- 
ation form (see “Attachment A” on page 9). 

• Too much standard s/w engineering basics; not enough knowledge-based related material 

• Less emphasis on basics and more in depth exploration of techniques/guidelines 

• Course should probably be longer to allow a bit more detail on techniques 

• More abstract examples 

• More examples of what an ES is. This hard for one to pick up with no previous experience in ES. 

• Preferred a shorter class focussing on specific techniques in great detail 

• Split the workshop into two pieces: basic concepts and techniques 

• Course is more of an overview - more detail on techniques is needed 


6 Students learned that, on average, inspections find roughly sixty percent of all errors. 


Results 7 



• Course was too long and the team exercises too drawn out 

• The “References” at the end of each section make the course excellent and very useful 

• Improve the quality of video presentations 

• Present instructor “solutions” to team exercises on the last day 

• Better student attendance would have helped when applying techniques to team exerases 

• Course should have had a real-world problem (using G2) with terminals for each student where students 
could apply specific analysis techniques 

Observations/Recommendations of the Instructors 

The follow in g are suggestions for improving on the work done with the ES V&V workshop: 

• Do a better job of “screening” people wishing to take the class 

• Leant about G2 and have examples on how to apply V&V techniques to a G2 rule-base 

• Advertise the workshop as two two-day workshops: "Basic Concepts” and “Techniques/Guidelines 

• Spend more time on techniques with improved examples and more detailed discussion 

• Teach a management version of this workshop 

• Fund future work in automating some of the better techniques; many of the techniques lack automation 
and therefore will be minimally used 

• Improve the use of video during the workshop. For example, a video could be made illustrating (via 
some “role-play”) a knowledge acquisition process and application of knowledge correctness techniques 

to that process. 

• Develop a “corollary" workshop on how to build verifiable ES (using techniques such as “cleanroom ) 

• Spend some time discussing what to do when you already have the system done and that system was not 
built using a V&V approach 
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CLASS EVALUATION 


Your input helps us improve course offerings. 


Date; 


Course Name 


In s tr u ctor 


Your Name (Optional): * ■ — 

(circle one response) 

l - Very 2 - 3 “ Neither Satisfied 4 • Dis sa ti s fi ed 5 ■ Very D i ssa tisfi e d 

? _ J 

QDT 1 


OVERALL 

1 2 3 4 5 Haw satisfied are you with dds ed u c a ti onal experience? 


What influenced your answer? (drcie am res po nse par factor) 

1 - Very Positively 2 - Positively 3 *»'N b Influence 4 - Negatively 5 - Very Negatively 


I 

I 

I 

1 

I 

I 

I 


2 3 4 
2 3 4 
2 3 4 
2 3 4 
2 3 4 


5 

5 

5 

5 

5 

5 

5 


1 2 3 4 5 
1 2 3 4 5 
1 2 3 4 5 


5 

5 

5 

5 

5 


1 2 3 4 5 


Course Contend DtBeery Factors 

a. Degree to which, the utilise met its 

b. Depth of the 
C. T migrti (jf the 

<L Effectiveness of the instructors) 



vmra s 


Satellite, etc.) 


•g. .Quality of the course 

Job Application Factors 
h. Availability of the 
L Relevance of the 


my job requirements 

to my job 



Fdncatinn ftrifities (feg. 


n. Travel (when applicable) 

o. T judging a pplicable) 


cfima t e , equipment, etc.) 


Other faeun 
p. Please specify 
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Handout #7: Exercises on General Techniques 


Define the "black box" view for your system. 
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Cunnb Time 
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Identify key terms from the problem description. 

yot*t tint % 

(nww>t fw* 

caUlimut , 

ckvrtA fa* 

tfW. 


3. 


Which of the following techniques would you use? Explain your answer. 
. Prototyping ^ pr**f | W i 

• Competing Designs 


Independent V&V 
Inspections 


e nhk ***** ‘ 
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4. Do a very high level specification for your system using one of the following 
techniques: 

• Decision Table 

. C ause- Effect Graph 

. State Diagram 








rtf 


c*HuU&. 
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Handout #8: Exercises on System Test 

Techniques 

1. Define 1 or more "realistic* test cases for your team exercise. 

avg * w«M( jm* ke avf * rtiuttb 
%e« if amkt\jp utft ***& ttbf 


2. Define some attrfoutes of your system. Define 1 or more test cases based on 
those attributes. 
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Define 1 or more test cases that do "boundary value" testing. 

fa# £ to tUtt i 


/ ** ^ 

<♦ 

i_J — L 
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* 
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/ <♦ 
i / -L 
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Define 1 or more test cases that "stress" test the system. 
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Define the external Interfaces to your system. Define 1 or more test cases to 
test those interfaces. 

I, re urv*.bt*uf l to 

** *f ******** 

~ on rtar»hmt «/«*“•*- •*** ' h 
7 , !*■*•*>**■ 


Define 1 or more test cases to test the system’s performance. 

M 4*4 ***** 

*y 1^1*** * 

juxtu hMdw* 4*4 
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7 . 


For each question, indicate how the results of each test case will be analyzed 
(i.e., how you will know the answer is correct). 


/. v£«lrtfcl M. - 

fit** 4ffX t&J ftty-Ck 

4. shr»« - *yrk rwv*v#i 

S'. i/» - teupkfo M/mvU 

8. Did the problem description provide enough detail to adequately perform the 

tests from questions 1*6? 

/k/o- k i» tf 

Ujikty ult 
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9. Develop a "certification" test for your system. 


10. Identify system \Hsast«re’ (i.e., things ttwrt should not happen). Explain how you 
will test your system for these "disasters". 

% 

pk*t syif 
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11. Will your project need the aid of an expert (provide rationale)? If so, indicate the 
kind of expert required and the type of analysis to be performed. 


12 . 


Define 1 or more models to aid in 
each model. 


your understanding of the system. Document 
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Handout #9: Exercises on Unit/Integration Test - 

Techniques 


1 . 


Pick an implementation approach for your problem. Based on this choice, would 
you use: g 


Coverage techniques 


h 



Am* 


Interprocedural data-flow analysis 

tk 


fret 


r. /« ) v - 

a 7eW«* <•<* *** *• ^ - 

TB ; Mi. . 

2 identify "part" of the system that may Impact reliability (HINT: you may have to - 

define what reliability is). Define 1 or more test cases to test those "parts . 


cj» A** «*** i< ••*** 
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4. 


Document 1 or more expected sequences of actions for your system. 

, p£vu tcMtJvJ* A 

* * 0 7*u- 

4# rwut 

ffcu*) 

Is "prototype evaluation" appropriate for your problem? What about mutation 
testing? Provide rationale. 

A t/M (fo 

T«h A *•**««•> 

OuUTt^u, 
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5 . 


Exchange your work with another team. Study the problem. Ask yourself the 
following: 

• Does their implementation match the problem? 

• Are there any "holes" or inconsistencies in their descriptions? 

• Did they pick the right techniques for their implementation approach? 

o 

t 
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Handout #10: Exercises on Static Test 

Techniques 


Identify and define at least 1 -object" in your system (remember, objects consist 
of both data and operations on that data). 


rk* , 

tU »*!*****“■ 

. pv\ir 
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2. 


Write a pre-condition and a post-condition for each operation on the object. 
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3 . 


Describe any general properties your "object" must satisfy. Discuss how you 
would analyze your "objecf’s implementation to "prove" those properties are 

always satisfied. 
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Pick at least one operation and defined some rules that implement its 
specificiation. 
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Select one of the following techniques for analyzing these rules. Explain your 
answer. 


Petri Nets 
Directed Graphs 
Connectivity Matrices 
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Identify 1 "hazard" in your system. Build a fault tree for that "hazard". 
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a fault tree for that "fault". 
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Handout #7 : 


Exercises on General Techniques 


1 . Define the "black box" view for your system. 
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Identify key terms from the problem description. 

C Ksv, PiueuJ) 

C?QAL5 C C/^UXXf 

fktM&rts ( CoLOiK < L****~) 

Acric** C Hou>, 


\v rrwu Co^omotJ* 

bcmJ> A** A&rxvJi ARB. 


Which of the following techniques would you use? Explain' your answer. 
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4. Do a very high level specification for your system using one of the following 
techniques: 


Decision Table 
Cause- Effect Graph 
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Handout #8: Exercises on System Test 

Techniques 


Define 1 or more 'realistic" test cases for your team exercise. 


Aw scev/mio 'rmr tpoajjgs 
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Define some attributes of your system. Define 1 or more test cases based on 
those attributes. 

LOlM&> ~ CtoJ "THE /VloAJKM 

£>&T ^5rrv*e* 

LOCATION "70 /foJOTtf&Z, 


1 


Handout #8 


3. 


Define 1 or more test cases that do "boundary value" testing. 


Ob 'THt- 
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4. Define 1 or more test cases that "stress" test the system. 
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5. Define the external interfaces to your system. Define 1 or more test cases to 
test those interfaces. 

OP 

fc&TAOUStt)*** 'THIz 
Initial aOA^orm^J. 


6. Define 1 or more test cases to test the system's performance. 
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7 . 


For each question, indicate how the results of each test case will be analyzed 
(i.e., how you will know the answer is correct). 

OP 

O&AL. 


8. Did the problem description provide enough detail to adequately perform the 
tests from questions 1*6? 

y«' 
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9. 


Develop a "certification" test for your system. 


fuLL, 


/ 


10. Identify system "disasters" (i.e., things that should not happen). Explain how you _ 
will test your system for thwe "disasters". 
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11 . 


Will your project need the aid of an expert (provide rationale)? If so, indicate the 
kind of expert required and the type of analysis to be performed. 



12. Define 1 or more models to aid in your understanding of the system. Document 
each model. 

4ene*->s op A P&T 
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Handout #9: Exercises on Unit/Integration Test 

Techniques 


Pick an implementation approach for your problem. Based on this choice, would 
you use: 

Coverage techniques 
Interprocedural data-flow analysis 


imerpruueuuicu wcu» uw** 
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Document 1 or more expected sequences of actions for your system. 

LX&JK&f Picks lop, Holds 
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Is "prototype evaluation’ appropriate for your problem? What about mutation 
testing? Provide rationale. 
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pre-condition and a post-condition for each operation on the object. 

Go*- ‘ioV** 


Handout #10: Exercises on Static Test 

Techniques 


Identify and define at least 1 "object" in your system (remember, objects consist 
of both data and operations on that data). 
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Describe any general properties your "object" must satisfy. Discuss how you 
would analyze your "objecf’s implementation to "prove" those properties are 
always satisfied. 

CfkJ be 
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3m re DiAAr**. 


Pick at least one operation and defined some rules that implement its 
specification. 
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Select one of the following techniques for analyzing these rules. Explain your 



Directed Graphs 
Connectivity Matrices 


Identify 1 "hazard" in your system. Build a fault tree for that hazard . 
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Handout #1 1 : Exercises on Guidelines 


i. 


Determine whether the recommended approach fits your problem. Identify 
additional issues that need to be considered. 




2. Generate a detailed development plan for your problem. Try to include specific 

milestones and how they will be achieved. 

a toamus - / 

, c * : £si 



3 . 


Define specific development increments. Update your plan to reflect those 
increments. 



'pfK&O&J . 5 



4. Consider the test cases you have selected so far. Are there any other kinds of 
testing you need to do? When will you know when to stop testing? 
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Build a high-level requirements outline for your system. How well does the 
original problem definition map to your outline? 

FtfJO UfafatiS 
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Handout #7: 


Exercises on General Techniques 


1 . Define the "black box" view for your system. 
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2. Identify key terms from the problem description. 

- fas fkiy fy 

- 6^u<vls 

- Ck«cL 

- (4«*J IhVk rJr *luVf»j 

”Xfv+*rM''4<K^' 

’ frMj* 4 w*s 

3. Which of the following techniques would you use? Explairt your answer. 

• Prototyping — Ubtf* 

• Competing Designs 

• Independent V&V - +edr Mi *5^ 

• Inspections •» tele 
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4. Do a very high level specification for your system using one of the following 
techniques: 


* • 


Decision T able 
Cause-Effect Graph 
State Diagram 
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Handout #8: Exercises on System Test 

Techniques 


1 . Define 1 or more "realistic" test cases for your team exercise. 

v 

TC t *■ ' l* rf try 
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2 . 


Define some attributes of your system. Define 1 or more test cases based on 
those attributes. 


Peliikdh 
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3 . 


Define 1 or more test cases 


that do "boundary value" testing. 



4. Define 1 or more test cases that "stress" test the system. 
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Define the external interfaces to your system. Define 1 or more test cases to 
test those interfaces. 


6. Define 1 or more test cases to test the system's performance. 

77*« i s. retailed f* 
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7 . 


For each question, indicate how the results of each test case will be analyzed 
(i.e., how you will know the answer is correct). 


-Az/ttWi tv>hr* ** b> t** <f 

cc-n itkJ" it’)' 


8. Did the problem description provide enough detail to adequately perform the 
tests from questions 1*67 
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9 . 


Develop a "certification - test for your system. 


$fVnul*i"£ 'Af to?*pQ/rt 
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10. 


Identify system "disasters" (i.e., things that should not happen). Explain how you 
will test your system for these "disasters". 
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1 1 . Will your project need the aid of an expert (provide rationale)? If so, indicate the 
kind of expert required and the type of analysis to be performed. 

/©•p'e.. 

12. Define 1 or more models to aid in your understanding of the system. Document 
each model. 


* Made] user idvrhct . 

♦ * ppfet-f d«^jraw\ . 
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Handout #9: Exercises on Unit/Integration Test 

Techniques 


1 . Pick an implementation approach for your problem. Based on this choice, would 
you use: 

• Coverage techniques 

• Interprocedural data-flow analysis 

- fifk f'/vrtJf Clow Uf pwMc 

** km} 

2. Identify "part" of the system that may impact reliability (HINT : you may have to 
define what reliability is). Define 1 or more test cases to test those "parts". 

TC * K 4 
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Document 1 or more expected sequences of actions for your system. 


(>r> $*$ / 
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Is "prototype evaluation" appropriate for your problem? What about mutation 
testing? Provide rationale. 
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5 . 


Exchange your work with another team. Study the problem. Ask yourself the 
following: 

• Does their implementation match the problem? 

• Are there any "holes" or inconsistencies* in their descriptions? 

• Did they pick the right techniques for their implementation approach? 
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Handout #10: Exercises on Static Test 

Techniques 


Identify and define at least 1 "object" in your system (remember, objects consist 
of both data and operations on that data). 
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2 . 


Write a pre-condition and a post-condition for each operation on the object. 
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Describe any general properties your "object" must satisfy. Discuss how you 
would analyze your "object's implementation to "prove those properties are 
always satisfied. 

• Dekrr*i<'i'V) 

yWI*.W 


4. Pick at least one operation and defined some rules that implement its 

specification. ^ 

( dtCrudjL, CdAttylt- 
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5 . 


Select one of the following techniques for analyzing these rules. Explain your 

ancuuor 



6. Identify 1 "hazard" in your system. Build a fault tree for that "hazard". 
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7. Identity 1 "fault" in your system. Build a fault tree for that "fault". 


V 
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Handout #1 1 : Exercises on Guidelines 


1. Determine whether the recommended approach fits your problem. Identify 
additional issues that need to be considered. 


2. Generate a detailed development plan for your problem. Try to include specific 
milestones and how they will be achieved. 

- 'ftf'p . 

Pkt aj roCfS’n^^. 

to*./ rtzr c.Lt> 

«A J/r///jTF&>. r^rr 
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ORIGINAL PAGE IS 
OF POOR QUALITY 


3. Define specific development Increments. Update your plan to reflect those 
increments. 

j 





do U'Zh' P^ f & 
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4. Consider the test cases you have selected so far. Are there any other kinds of 
testing you need to do? When will you know when to stop testing? 


tiA. sH 
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Build a high-level requirements outline for your system. How well does the 
original problem definition map to your outline? 

Am» 5 TjfT L .lfLS~LS/ 

Tt> t+rf-uer t c_ Cf'-O 

CmJuL * 

BxTTiTKy 

rcuCjS 

57 << 


3 


Handout #11 


Handout #7: Exercises on General Techniques 


1 . Define the "black box" view for your system. 



A*#* y ^ 


i 


Handout #7 



2. Identify key terms from the problem description. 

^ T ^ r^t X >'Jr f ***■ 

$«co*fc»/y f 
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3. Which of the following techniques would you use? Explain your answer. 

• Prototyping 

• Competing Designs 

• Independent V&V 

• Inspections 
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4. Do a very high level specification for your system using one of the following 
techniques: 

• Decision Table 

• Cause-Effect Graph 

• State Diagram 





Handout #8: Exercises on System Test 

Techniques 


Define 1 or more "realistic" test cases for your team exercise. 

to *r%. 


Define some attributes of your system. Define 1 or more test cases based on 
those attributes. 
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3. 


Define 1 or more test cases that do "boundary value" testing. 


z. r ^ 
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4. Define 1 or more test cases that "stress" test the system. 


I IO °/o +■ A * 

Seca*. y 7 “ «*•&, 5 “ 


2 


Handout #8 



5 . 


Define the external interfaces to your system. Define 1 or more test cases to 
test those interfaces. 


eor«c+ Ca* ,w 


6. Define 1 or more test cases Jo test the system's performance. 
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7 . 


For each question, indicate how the results of each test case will be analyzed 
(i.e., how you will know the answer is correct). 
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8. Old the problem description provide enough detail to adequately perform the 


tests from questions 1-6? 
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9. 


Develop a "certification" test for your system. 


s I* «.m4 6. 

7VS4* *«.«*.*' cD, 


10. Identify system "disasters" (i.e., things that should not happen). Explain how you _ 
will test your system for these "disasters". 
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1 1 . Will your project need the aid of an expert (provide rationale)? If so, indicate the 
kind of expert required and the type of analysis to be performed. 

Vei # Cetv w Vs l/alwi 

©>•« l «I«Pm«cI o.'aA 

net Aok . 

12. Define 1 or more models to aid in your understanding of the system. Document 
each model. 
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Handout #9: Exercises on Unit/Integration Test 

Techniques 


Pick an implementation approach for your problem. Based on this choice, would 
you use: 


• Coverage techniques 

• Interprocedural data-flow analysis 

Co**. V a*n^'ov\ 


Identify "part" of the system that may impact reliability (HINT: you may have to 
define what reliability is). Define 1 or more test cases to test those "parts". 
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3. 


Document 1 or more expected sequences of actions for your system. 


6 Cr Is 


4. is "prototype evaluation* appropriate for your problem? What about mutation 
testing? Provide rationale. 


chujc 
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5. Exchange your work with another team. Study the problem. Ask yourself the 
following: 

• Does their implementation match the problem? 

• Are there any "holes" or inconsistencies in their descriptions? 

• Did they pick the right techniques for- their implementation approach? 
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Handout #10: Exercises on Static Test 

Techniques 


1 . Identify and define at least 1 "object" in your system (remember, objects 
of both data and operations on that data). 
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2 . 


Write a pre-condition and a post-condition for each operation on the object. 
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3 . 


Describe any general properties your "object" must satisfy. Discuss how you 
would analyze your "objecf's implementation to "prove" those properties are 
always satisfied. 


^ /ws a ; v%w w, *vi 


4. Pick at least one operation and defined some rules that implement its 
specificiation. 
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5 . 


Select one of the following techniques for analyzing these rules. Explain your 
answer. 


Sw*. 


Petri Nets 
Directed Graphs * 
Connectivity Matrices 



Identify 1 "hazard" in your system^u'lcf^’fau^tree for that "hazard" 
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7. Identity 1 "fault" in your system. Build a fault tree for that "fault". 
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Handout #1 1 : Exercises on Guidelines 


I. Determine whether the recommended approach fits your problem. Identify 

additional issues that need to be considered. 
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'€ 6\r€* (/# I K 


2. Generate a detailed development plan for your problem. Try to Include specific 
milestones and how they will be achieved. 
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3 . 


Define specific development increments. Update your plan to reflect those 
increments. 
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4. Consider the test cases you have selected so far. Are there any other kinds of 
_ testing you need to do? When will you know when to stop testing? 
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5 Build a high-level requirements outline for your system. How well does the 

original problem definition map to your outline? 
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Welcome 


Welcome to the Overview on Verification 
and Validation (V&V) of Expert Systems 

This Overview provides 

• A view of the "state of the practice" 
in V&V of Expert Systems 

• insight into what we have taught 
developers about V&V 

» Many Techniques 

• Guidelines for management's role 
in V&V 

» Developers stressed need for 
management involvement 

Test 

Design 

Requirements 

Plannkng 

Project Management 
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"State of the Practice" in Expert 
Systems V&V 


Significant research has been done in 
Expert Systems V&V 

• Developed conceptual approaches 

• Proposed various techniques 

No significant case studies or field 
demonstrations 

Research is based on many conjectures 
about how Expert Systems are built 

• Expert Systems have no 
requirements 

• Small V&V effort for Expert 
Systems compared to other 
software 

• Testing an Expert System is hard 
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Survey ctatP-nf-the-practice in ES V&V 
. Determine real issues in V&V of ES 
. Assess accuracy of conjectures 
. Impact future work in V&V of ES 

60 + projects were asked questions such as- 
. V&V activities done, not done 

• Issues that occur in practice 

• Extent to which V&V impacts 
issues 

• User views of quality/reliability 
Caveats 

• Results are not statistically valid 

• Responses reflect opinion 

‘The survey did not attempt to assess whether a given system was good or bad. Our goal was to uncover 
issues encountered. 
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"State of the Practice” in Expert 
Systems V&V ... 


Major difficulties developers experience 
when building Expert Systems 

• Determining when to stop testing 
(63%) 

• Validating knowledge acquired 
from the expert (60%) 

• Managing the complexity of the 
problem being solved (40%) 

Process used in building an Expert System 

• 22% followed no life-cycle model 

• 43% built operational prototypes 

• 14% cited Configuration 
Management as an issue 

» One-on-one interviews 
indicated greater concern 
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’’State of the Practice” in Expert 
Systems V&V ... 


Methods used in verifying and validating 
an Expert System 

. 57% operational systems had no 

requirements 

• 52% used only one technique 


Resulting quality of the Expert System 

. Considered both developer and 
user perspective 


Item 

Dev Users 

Evaluation is difficult 
Less accurate than Expert 
Did not meet expectations 

27% 100% 

44% 80% 

49% 100% 
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Addressing the Issues 


Survey indicates ES projects need help 

Two presentations address those needs: 

• Management overview of V&V 

• Developer instruction in doing V&V 
(Workshop on V&V of ES) 

These presentations seek ... 

To help project members 
"pull together" for higher 
quality results ... 


And avoid 
this! 


Additional work still needed in many areas 
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ES Developer Workshop on V&V 


Workshop is taught over a 4 day period 

Goal is to help developers do their job 
better 

Many topics covered 

• Theoretical basis for V&V 

• Planning for V&V 

• 47+ techniques covered 

• Guidelines for doing V&V 
Developers learn by 
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What is Verification and Validation? 
Verification : Am I building the product 
right 

. Did I do what I was told to do 

Most techniques address this 

. Therefore, generally easier to 
satisfy 

Validation : Am I building the right product 

. Was I told the right thing to do 

. Few techniques help with this 

. Therefore, generally more difficult 
to satisfy 
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Key Points Develo pers Learn ... 


Focus on finding errors early 

. Follow a "test as you go" approach 
• Emphasize human analysis 


Phases of Correctness Testing 



Static Testing 



"It is not uncommon to spend 
30 to 50 percent of the ... cost 
... for the verification effort 
using the after-the-fact 

approach''^ 
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Spend more time analyzing the problem 

. a complete understanding of the 
problem is never initially possible 

. Will use prototyping to model their 
understanding of user needs 

. Translation : "Pay me now or pay 

me later" 

Insist on following a development life-cycle 
. No more "operational” prototypes 



"Building large programs is 
NOT like building small ones 
and software engineering is 
different from most other 
engineering disciplines'^ 
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Key Points Developers Learn ... 


Plan for V&V 

• Match implementation to problem 

» Solution-oriented vs. Technology- 
oriented 



"Many problems that occur ... 
are the result of ... generating 
code without thinking about 

the design."^ 



Survey indicated 45% of 
Expert Systems mix 
conventional and procedural 
code. 


• Identify required resources 

» Hardware, Software, expertise, ... 

» All impact the project’s feasability 
» Should be done early instead of later 
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Plan for V&V ... 

. Prioritizing tasks (e.g., do the 
critical things first) 



"A comprehensive test 
management approach 
recognizes the differences in 
objectives and strategies of 
different types of testing .” 10 


. Remembering that the system will 
have to be maintained 



For every dollar spent in 
development, two dollars is 
spent on maintenance . 2 
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Key Points Developers Learn 


Build a description of the problem 
• Have something to test against 



"If an expert system starts 
with vague objectives, some 
may conclude that it doesn't 
matter what the eventual 
system does, because 
anything is better than 

nothing." 4 


• Must be a "crisp” definition 



"Knowledge-based systems 
have a greater liklihood of 
succeeding - and, in a sense, 
of being valid - when they 
address a narrowly defined 

problem."? 
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on doing M smart©r tosting 

Matching the right technique to the 
right problem in the right situation 

The Verification Puzzle 



Develops an understanding of why 
the system is correct 

Know when to stop testing 





Kev Points Developers Learn ... 


Expect the system to work 

• Confidence in applying techniques 

• Confidence that the appropriate 
issues have been considered 

• Confidence that the problem can be 
solved 


"A good programmer 
understands what his 
program is supposed to do 
and why he expects his 
program to do it."5 

'The difficulty with low 
expectations is that they 
become self-fulfilling. "5 






Guidelines 


The following ere guidelines to be followed 
when applying V&V to your pro|ect 


YOU may want to do these yourself or 
delegate them to members of th 
development team 


Just make sure they happen 

Guidelines apply to the following steps 

^fesT 

Design 

Requirements 

Planning 

Project Management 
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Guidelines 


Project Management 

• Include V&V as part of the cost of 

developing software 

» Spread throughout the development 
cycle 

» Not all at the end 

• Allocate resources for V&V 

» Be prepared to postpone a project if 
the resources are not available 

» For expert systems, you will need the 
expert's time for V&V 

• Make sure you follow a systematic 

development approach 

» Best bet is to use a life-cycle model 
that includes major testing phases 

» Focus on a "test as you go" 
approach 
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Guidelines 


Project Management ... 

. Make sure your plan is based on 
the system's characteristics 

» What problem is to be solved 

» Complexity of that problem 

» Effort required to generate a solution 

» Types of correctness that matter 

. Include prototyping to help validate 
understanding of the user s needs 



"The only question is whether 
you or y? 1 , 11- customer will 

discover them (errors)"® 

"... there is now less excuse 
than ever for not involving 

users early on ..." 1 


» Separate prototyping from complete 
system development 
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Guidelines ... 


Problem Analysis 

• Narrow the scope of the problem as 
much as possible 

» Better to have a system that solves 
one problem really well than a 
system that solves many problems 
poorly 

• Do not force the solution to be an 
expert system 

Requirements 

• Write Requirements 

• Impossible to prove anything about 
the system without it 

» Consider all kinds of correctness 

• Make sure that (at a minimum) the 
expected use of the system is 
defined 





Guidelines 




Design 

. Pick methods that make static 
analysis easier 

» Easier and less costly system test 


. Map requirements to design 

» Helps decide if anything is missing 

. Pick a reasonable design notation 
and stick with it 



"... conceptual integrity is the 
most important consideration 
in system design. It is better 
to have a system ... reflect 
one set of design ideas, than 
to have one that contains 
many good but independent 
and uncoordinated ideas. 3 
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Guidelines 


■ ■ ■ 


Test 

• Consider using an independent 
organization for final V&V 

» A "fresh look" can often find 
additional errors 

• Use test techniques that find errors 
as early as possible 

• Do not forget to do regression test 

» Easier when following a "test as you 
go" approach 

• Prioritize the test approach 

» Focus on critical functions first 
» Test others later as resources permit 



IsS 


Bn*— I 
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Conclusion 


Doing the right things will produce the 
right results 
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Conclusion ... 


Just remember 


• Software engineering is not easy 



"Software engineering is 
harder than you think, i can 
not emphasize strongly 
enough how true this 
statement is. "9 


• Expert Systems are software 



"Al entails massive software 
engineering."9 



They do not work "like 
magic” 
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